大型集团如何构建数据网格架构
每当开始与新客户合作时，我留下深刻印象的是：当开始围绕数据展开讨论时，绝大多数利益相关者开始谈论数据库表。更令人印象深刻的是，这种方法通常是由业务用户驱动的。我无数次听到企业业务部门说他们需要一组给定的表，以及需要针对这些表运行哪种类型的联接、分组依据和选择。所发生的情况是，重点是技术细节，而不是解决方案应提供的数据集方面的预期结果。
从某种角度来看，当我们设计解决方案的数据架构时，常常落后于最先进的软件设计方法。在老式的瀑布模型方法中，同一企业告诉其软件开发团队他需要一个功能、一个Web应用程序、一个Web服务或一个数据库，这是很常见的。基本上，它并不是告诉他需要什么，而是告诉团队应该做什么来实现他认为需要的工件。这种方法有几个问题，我想重点讨论这些问题：
企业是其业务领域的专家，他们可能不知道最先进的技术解决方案。他对所需工件的设想可能与最佳解决方案相差甚远。
过于关注任务，项目很可能会失去对可以为解决方案增加价值的内容的控制，从而导致浪费精力来添加无用的功能。
敏捷方法有助于解决这些行为：项目的重点是业务成果而不是任务和时间管理。如果某个功能为企业带来价值，它将被实施，并且技术团队将决定如何实现它。我会强调产品负责人的角色，它纯粹关注业务需求并为团队提供决策所需的信息。通过敏捷方法，每个人都专注于其优势，并且只与为解决方案增加价值的内容相关，而不是与预先规划的合规性相关。
正如我们将要看到的，数据网格模式引入了一种新的思考数据工件的方式，称为数据产品，其目标是用业务术语描述系统应提供的信息集，将重点放在什么而不是如何。此外，该模式增强了去中心化的组织模型，将数据生产者、可以构建数据产品的用户（最好是业务用户）与负责构建技术蓝图（通常由IT团队实现）的基础设施管理功能分开。该模型简化了分布式数据的管理，增强了协作和重用，并允许采用最先进的技术来管理端到端的数据流。
在接下来我们讨论：
为了严格控制一切而采用集中式数据处理方法，与为了反映业务用户所需的灵活性而创建分散式孤岛之间的矛盾，两者之间永无止境。
数据网格方法如何解决这个问题，明确区分IT职能的角色，负责提供蓝图和标准，而其他职能则负责使用这些蓝图构建数据产品。
数据仓库
从架构的角度来看，我相信任何参与数据管理系统定义的人都熟悉经典的数据仓库架构：
数据仓库架构
在数据流开始时，我们的数据源通常是企业应用程序，提供结构化数据，并使用ETL过程将其移至数据仓库(DWH)，该过程基本上重塑、协调和集中传入的数据。通常，DWH不包含源数据的副本，它只存储ETL过程的结果；有时，为了简化调试和问题解决，最后一段分析数据存储在DWH摄取表中（根据业务场景，可以是一小时、一天、一个月等）
在某些情况下，特别是当数据很复杂时，会引入一个附加层，即数据集市，其目标是将来自不同DWH的数据放在一起，或者重塑DWH定义的数据以方便使用；例如，对于给定的一组报告，可以在数据集市中重新组织数据（例如：定义星型模式），以便更符合报告框架技术。
对于大型国际公司来说，管理多个物理数据仓库是很常见的：
不同的国家可能有不同的法规，因此他们需要以不同的方式塑造相同的信息。
一些国家可能要求数据不得存储在该国境外；在这种情况下，只允许本地仓库。
不同的部门对相同信息的处理方式可能不同：一般来说，销售人员描述客户的方式可能与会计或财务部门的方式有很大不同。
不同部门可能有不同的数据速度要求：例如，在物流行业中，财务部门可以满足每日或每周的数据更新，而运营部门则需要更快的更新（甚至同一小时内更新更多次）
因此，即使DWH模式在理想情况下旨在为整个组织构建独特的数据存储，但也有一些现实场景无法满足此目标。为了保持平衡，IT部门尝试将DWH数量保持在最低限度，因为DWH存储通常很昂贵，并且运行数据库引擎需要昂贵的软件许可证，因此限制基础设施规模有助于限制成本。
无论如何，传统的DWH数据管理方法会带来以下问题：
找到主数据通常很困难：例如，一个大型组织内可能有数十种不同的信息系统可以管理客户信息，每一种都有自己的密钥和属性，并且了解要管理哪些信息可能并不那么简单采用和丢弃哪些。
一旦数据存储在DWH表中，就很难理解信息的来源：表x的数据源是哪些？他们如何合作制作最终数据集？
鉴于与源系统的高度集成，添加更多数据源可能会非常复杂且成本高昂，并且可能需要较长的分析和实施过程。
看起来，拥有多个简单的数据仓库（每个数据仓库都针对特定领域进行了精心设计）可能是比拥有一个共享的庞大结构更好的方法：我相信这与事实相差不远（顺便说一句，我'在许多组织中都经历过这种方法）。然而，这种设计解决方案可能意味着总体成本的显着增加，因为可能需要更多的数据库许可证。
整个组织的信息分发
假设有一家公司，我们称之为“某大型能源集团”，为简单起见，该公司有一个三层组织：
L1：集团
L2：事业部
L3：部门
集团分为事业部，事业部又分为部门。IT团队代表部门之一。出于数据管理的目的，IT提供集中式数据仓库和一些本地数据存储来为特定的事业部和部门提供服务。为了生成企业报告，开发了一个包含中央数据仓库和其他业务关键本地数据库的数据集市。每当中央DWH需要更新时，都会启动一个IT项目并进行数据流分析，以了解业务需求以及对现有解决方案的影响。本地数据库通常由事业部或部门主导的项目开发并由外部供应商实现。在这些项目中，IT发挥治理作用，检查公司准则的合规性并确保生成的工件的质量。将上线项目工件纳入IT运营流程。
考虑到场景，让我们思路下：每当一个部门需要分析一组新信息时，可能会发生什么情况？
根据我的经验，请求者将不得不面临两种选择：
将一组新表添加到集中式数据仓库，启动分析项目，以确定所需的数据源、可能的冗余和可能的集成问题。
在IT治理的帮助下与供应商启动一个新项目，构建一个新的本地数据仓库来管理新数据。
选项2通常比选项1更快，但通常意味着“重新发明轮子”，因为部分数据可能已经在现有解决方案中可用，但为了速度而牺牲了重用。当时间充裕时，很可能会选择方案1。反复迭代此方法，结果将如下图所示。
整个组织的数据分布
缩小并从公司范围的角度来看，我们会看到几个数据存储（数据仓库、数据库、数据湖等），它们保存与特定组织级别相关的信息：一些可以存储对特定事业部有用的信息，另一些可以存储对特定部门有用的信息。对于特定事业部，少数可以保存跨部门甚至整个组织的相关信息。
那么，哪些是企业级信息呢？我们怎样才能建造它？根据我们要运行的分析类型，很可能会选择一组不同的数据存储；数据将被转换和协调，以具有与企业级别相关的通用形式。与上层的技术形式无关：它可以是数据集市、数据仓库、数据湖等，无论其技术形式如何，该层代表了分布在整个公司的有价值的信息的组合。
分布式数据
某大型能源集团的例子显然并不完全符合世界上任何公司的情况，但它是许多公司的良好原型，至少是我在过去15年中一直合作过的公司。有一句话我非常喜欢，很适合放在这里：
拥抱现实并应对它。
事实上，在复杂的组织中，信息往往是分布式的而不是集中式的，并且在许多情况下，企业更喜欢开发自己的孤岛而不是合作构建集中式平台。决定这是对还是错不在本文的范围之内，但它确实发生了。通常，IT部门为了治理而希望集中所有内容与业务用户为了速度和灵活性而希望分散所有内容之间存在斗争。
数据网格有助于在这两种态度之间找到平衡，在IT和业务职能之间分配角色和职责，从而在IT治理和业务灵活性之间找到匹配。通过这种方法，我们消除了信息存储方式及其使用的存储类型的技术细节，用业务术语对其进行描述，以便该领域的任何人都可以理解。组织：重点是内容。更具体：
每个数据工件都应该有一个明确的所有者，对其定义和内容负责：任何时候有人想要了解其目的，都必须清楚他需要联系谁，即数据所有者。
每个数据工件应该公开它正在从哪些其他数据工件获取数据，换句话说，它必须公开其血缘。
从IT角度来看，IT组织负责两项任务：
它提供了构建工件严格要求的一组策略和标准。团队使用哪一种并不重要，但它必须符合标准。换句话说，IT功能提供了构建内容的基础设施，它定义了架构蓝图。
它监视生成的工件，创建组织内所有可用内容的数据目录，对数据所有者进行普查并跟踪每个工件的完整数据沿袭。IT职能部门将使用这些数据来增强整个组织内的工件重用。
正如某大型能源集团示例中所讨论的，IT可以与外部供应商一起参与工件的实现，但其中任何一个都将作为集中式基础架构中的本地项目来实现。
数据网格架构
让我们退后一步，定义一些稍后会用到的关键术语；考虑以下两个事实：
每个应用程序，至少在数据管理的上下文中，都会生成和使用数据：它可以位于应用程序RAM、文件、数据库、数据流等中。
每当一个应用程序需要与另一个应用程序共享其数据时，我们就需要实现一个数据集成层：通常，该集成层具有ETL/ELT管道的形式，但它可以是任何类型的转换，以使数据来自应用程序A.对于应用程序而言可以理解B.
考虑到这两个事实，我们可以综合从应用程序A到应用程序B的数据传输，将应用程序A标识为数据提供者，将应用程序B标识为数据消费者。
提供者/消费者模式
数据提供者：它代表正在生成所需数据的应用程序；数据预计为所有者（通常是应用程序所有者）所知并拥有。
数据消费者：它代表在特定上下文可以是公司组织单位、项目团队等内出于自身目的使用数据的应用程序。消费者也可以是生产者。
注意：数据集成是一个复杂的主题，假设您脑海中浮现出几个问题：
数据集成是否意味着将数据从提供者复制到消费者？
如果我们发现应用程序A中的数据错误或损坏，应用程序B会发生什么情况？
当然，数据复制可能会导致相同信息的本地副本激增，从而产生指数级存储消耗并使错误修复变得非常复杂。。
基本上，数据集成是不可避免的。无论应用程序A和B的范围和目标如何（它们可以是两个业务应用程序，一个业务应用程序和一个数据仓库等），我们都需要集成它们，因此我们的重点应该是使这种集成变得简单尽可能。为了利用这个想法，我们将集成中共享的信息命名为“数据产品”。让我们定义数据产品的一些关键属性：
它应该可供广泛消费。
它应该用通用语言表达。
它应该有一个明确且众所周知的所有者。
它应该与其上下文保持一致。
它不应该符合数据消费者的特定需求。
它应该与源应用程序数据管理模式解耦。
它应该直接从源公开，而不是通过其他系统进行混淆。
它从创建之日起就应该保持兼容。
它应该遵守中央互操作性标准。
它可以构建在其他数据产品之上。
这个想法是让可识别的所有者提供的工件能够提供有意义的信息，而无需知道或理解其源应用程序技术或数据结构。换句话说，数据产品是用业务术语来表达的，是为了满足业务需求而生成的，而忽略了所有的技术细节。
我们说过，每个数据产品都存在于一个上下文中：我们将其命名为DataDomain。数据域代表围绕共同业务目的组织的一组人员，他们可以是同一组织单位、同一项目等的一部分，这些人员生成遵循上述要求和公司质量标准的数据产品。
数据域/数据产品层次结构
考虑到这一点，并记住数据仓库已经整合了来自源应用程序的数据，我们可以重新考虑整个公司的数据分布，将其视为不同数据域的数据产品的生产：
整个组织的域分布
数据网格架构认为数据产品分布在整个组织中，并提供工具和技术来完全控制生成的工件，并确保底层技术符合公司标准，遵循质量和安全标准和约束。重点不在于如何将信息流集中到单个存储或一组有限的存储中，而是在受控环境中增强对公司信息增长的分布式贡献，制定规则并提供在更高水平时打包信息的方法。换句话说，本地团队可以从一组已经认证的工具中选择他们最喜欢的工具，来构建为其业务目标带来价值的数据产品，而中央团队有一种方法来识别生成的工件及其所有权，并且他们有一种将所有内容放在一起并构建所生成信息的公司级视图的方法。
网格是特定于域的数据存储的聚合视图，用于生成更高级别的信息视图：
例如，假设我们需要构建某大型能源集团组织的财务报表：该公司在地理上分布有当地子公司，这些子公司按区域分组：
每个子公司必须制作自己的财务报表以符合当地法规，我们需要按地区汇总数据，然后我们需要有企业层面的视图。每个视图都将是域的一部分，并由代表其核心组件的一组数据产品定义。为简单起见，我们假设每个视图都是一个唯一的数据产品：
网格示例
结果将是一个数据产品网络：
每个数据产品都有一个明确且定义的数据所有者
数据消费的关系将定义每个数据产品的数据血统
通过这种方法，我们定义了一个干净的架构，具有以下优点：
只要有可能，每个数据产品都依赖于现有的数据产品，增强重用，限制与源应用程序（ERP、CRM等）的连接，并集中数据转换和清理逻辑。
每个数据产品都有明确的所有者：每当数据产品提供的输入出现问题时，谁应该调查该问题都有明确的责任。
采用完整的谱系有助于识别端到端数据链，阐明数据产品用于构建自己的结果的来源。完整的谱系还有助于了解其中一个项目中错误或损坏的信息集的影响。
小结
总之，我们看到，即使数据仓库等技术方法倾向于构建中央应用程序解决方案，但在大型组织中，数据和系统往往分布在不同的地理位置和组织单位。数据网格架构提供了一种平滑管理去中心化分析平台和数据存储的方法，对策略和平台保持严格的治理。
同时，由于数据产品的概念，数据网格架构支持定义良好术语和良好描述的工件，并具有明确的所有权，可供广泛使用并以自然语言描述。这有助于业务用户专注于他们需要的信息，而不是构建该信息所需的技术项目。
下面，我们将详细阐述这些主题，特别是：
我们如何有效地组织DataDomain？
采用数据网格方法有任何技术先决条件吗？一般来说，组织需要什么才能成功实施该模式？
我们如何处理数据集成模式而不创建相同数据的无数副本？我们可以采取哪些策略？
数据域理论
数据网格理论定义了三种数据域：
源对齐数据域：通过这种方法，数据域反映了操作平面定义的域。
与消费者保持一致的数据域：通过这种方法，数据域与从数据中提取价值并服务于特定用例的业务流程保持一致。
聚合数据域：通过这种方法，数据域混合了操作平面和业务流程的域结构。
由于聚合数据域仅在非常特定的场景中使用，因此将在以后的文章中讨论它们。
基本上，当我们使用与源对齐的数据域时，我们会靠近信息源。当我们使用与消费者一致的数据域时，我们与业务消费者保持密切联系，努力满足其业务需求。
通常，当我们设计公司应用程序环境的分析层时，我们倾向于将数据聚合到业务实体中，通常试图尽可能保持操作系统的特殊性。考虑到这一点，源对齐数据域可能看起来是一个奇怪的选择。当我们讨论数据网格模式的参考技术前景时，一切都会变得更加清晰，但是，现在，只需想想：
对来自源应用程序的数据进行分析是很常见的，因此将其数据产品像组织中的任何其他数据产品一样进行管理可能是一个好主意。
操作系统可以有不同的技术环境，很难满足数据网格分散方法的需求（例如：ERP通常是集中式解决方案，几乎永远不会允许业务用户随心所欲地使用数据）。
因此，考虑到协调整个组织的操作系统数据管理与数据域和数据产品定义的目标，源对齐的数据域是有意义的。
一般来说：
每当您使用与源系统非常相似的一组自洽信息时，就构建与源对齐的数据域。
每当您需要聚合来自不同来源的数据以试图反映业务实体和业务流程时，就可以构建与消费者一致的数据域。
DataDomains和企业组织
据我所知，DataDomains将包含数据产品，每个数据产品将由数据所有者管理。由于重点在于所有权，因此一种可能的方法是依靠企业组织来识别数据域。在这方面，有两种可能的做法：
数据域映射到企业组织单位，按组织所有权对数据产品进行分组。
数据域映射到逻辑功能，按业务目的对数据产品进行分组。
在第一个场景中，数据域将根据企业组织结构进行设计，组织中每个可识别的人员群体都可以代表特定的数据域：
某大型能源集团示例组织树
在上图所示的某大型能源集团示例中，每个组织单位都可以成为一个数据域，因此根据具体用例，我们可以拥有“Office1”、“Department2”、“Division1”等数据域。通过这种方法，数据产品、数据所有者和组织结构之间将有直接、清晰的对应关系。同时，我们将知道属于给定DataDomain的数据产品将为其所属的组织单位实现价值。
另一方面，将数据域映射到逻辑功能意味着要利用跨单元功能来定义它们。例如，您可以将数据域映射到项目：它们可以涉及来自不同组织单位的人员，因为通常需要具有跨职能技能的资源。
某大型能源集团面向项目的数据域
通过这种方法，DataDomain是围绕项目可交付成果的定义构建的，它们与组织结构或特定业务功能没有关系；相反，这些数据域可以分布在不同的业务功能中，从而导致数据所有者来自不同的单位：
跨职能DataDomain规范
项目只是跨职能项目的一个示例：数据域可以构建在有意义的信息区域上；“客户管理”可以是一个数据域，涉及企业中的多个组织（商业、会计、交付、产品管理等）。
分发DataDomain的一个好方法可能是利用数据所有权：所有权与企业的组织结构相关吗？如果是这样，也许最明智的选择就是遵循组织设计。如果数据所有权主要与成果项目或跨职能知识相关，那么使用跨部门数据域是明智的。
即使现在一切看起来都很简单，但现实总是比这复杂得多。考虑这种情况：
数据产品是由IT部门管理的运行项目构建的。
即使大多数项目服务于一个组织单位，但其中一些项目可以服务于多个组织单位。
所产生的数据产品的数据所有权可以分配给来自不同组织单位的用户，不同的项目可以根据管理的信息共享相同的数据所有者。
尽管使用跨部门方法看起来很简单，因为：
在数据生产方面，一个项目是自洽和完整的。
每个项目团队应该能够在一个隔离的区域自主工作，与其他项目/区域的依赖应保持在最低限度。
从项目的角度来看，“项目驱动的数据域”是一致的。然而，如果我们从数据所有者的角度来看，我们会遇到这样的情况：
业务领域的数据会分散在多个DataDomain中，缺少独特的信息视图。
数据所有者需要评估分散在多个项目中的信息。
即使我们简化了数据生产过程，但从数据业务意义的角度来看数据消费，它已经变得低效了。
在这种情况下，同时采用这两种方法可能是明智的。
混合数据域方法
这种方法的主要优点之一是我们将摄取与数据转换分离。数据进入系统保留其原始形状和含义。然后根据业务场景对数据进行转换、分组、合并、过滤以解决特定需求，并且这种转换始终是非破坏性的。
往期推荐